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(57) Abstract: The invention concerns a 
method for generating applicative software 
for management of a process using a system 
software common to all the applicative 
software. It comprises: a step of representing 
the process (32), using a very small number of 
classes of actions or generic objects, typically 
less than twenty, in at least a diagram of 
the application; a step of transcribing (33) 
each object of each diagram into an action 
corresponding to an object provided with 
attributes, each class of action or generic object 
being, during the transcription step, associated 
with an application data input interface; a 
step of transcribing the nodes, branches and 
end -nodes (34) of each diagram into an action 
corresponding to an object provided with 
attributes, a step of pre-compiling (35) which 
consists in verifying whether the attributes 
of the objects required for the application 
operational logic exist and are properly 
supplied, in syntax; a compilation (36) which 
consists in integrating and assembling the data 
specifications of the objects provided with 
attributes with the system software, to obtain 
an executable applicative software; and a step 
of executing (37) the executable applicative 
software. 
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(57) Abr£ge : Le proc&te de ggneYation de logiciel applicatif de gestion d'un processus met en oeuvre un logiciel systeme commun 
a to us les logiciels applicatifs. II comporte: une 6 tape de representation du processus (32), mettant en oeuvre un tres petit nombre 
de classes d' actions ou objets g6neriques, typiquement infe"rieur a vingt, dans au moins un diagramme de l'application, une 6tape 
de transcription (33) de chaque objet de chaque diagramme en unc action correspondant a un objct dote" d'attributs, chaque classe 
d'action ou objet gdncnque ctant, pendant l'dtape de transcription, associd a unc interface dc saisic de donnees d* application, une 
etape de transcription des noeuds, embranchements et feuilles (34) de chaque diagramme en une action correspondant a un objet dote 
d'attributs, une £tape de pre -compilation (35) au cours de laquelle on veYifie que les attributs des objets necessaires pour la logique 
de fonctionnement de l'application existent et sont convenablement fournis, en syntaxe, une 6tape de compilation (36) au cours de 
laquelle les descriptifs de donnees des objets dotes d'attributs sont integres et sont assembles avec le logiciel systeme, pour obtenir 
un logiciel applicatif executable, et une 6tape d'execution (37) du logiciel applicatif executable. 
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PROCEDE ET D1SPOSITIF DE GENERATION DE LOGICIELS EXECUTABLES SUR 
MESURE ET EVOLUTIFS SANS PROGRAM MATION INFORMATIQUE 



La presente invention vise un precede et dispositif de generation de logiciels 
5 executables sur mesure et evolutifs sans programmation informatique. Elle 
s'applique en particulier a ta generation de logiciels de gestion et de pilotage d'un 
centre de profits. 

Le processus de generation de logiciels actuellement connu est base sur la 
negotiation d'un cahier des charges entre le client et rinformaticien charge de 

10 realiser une application informatique repondant au cahier des charges, puis la 
programmation par un informaticien d'un logiciel correspondant au cahier des 
charges negocie. Le client ne maTtrisant pas les c.ontraintes techniques qui encadrent 
le travail de rinformaticien, la negociation est asymetrique et provoque, par elle- 
meme, une insatisfaction du client. En outre, toute modification ulterieure du logiciel 

15 est soumise a un nouveau travail de rinformaticien, ce qui gene 1'evolution de ce 
logiciel. 

La presente invention vise a remedier a ces inconvenients. En particulier, la 
presente invention vise a eviter I'intervention d'un informaticien dans la 
programmation ou la modification d'un logiciel. En d'autres mots, la presente 
20 invention vise a donner au client : 

- la maTtrise du processus operationnels de generation de 1'application, 

- d'6viter que I'application soit soumise aux modeles sommaires donnes par les 
informaticiens, 

- d'obtenir, en quelques minutes, une application informatique sur mesure, 
25 repondant integralement a ses voeux, sans avoir a maitriser de langage 

informatique. 

Selon un aspect, la presente invention vise un procede de generation de 
logiciel applicatif de gestion d'un processus, caracterise en ce qu'il met en oeuvre un 
logiciel systeme commun a tous les logiciels applicatifs et en ce qu'il comporte : 
30 - une etape de representation du processus, mettant en oeuvre un tres petit 
nombre de classes d'actions ou objets g6neriques, typiquement inferieur a vingt, 
dans au moins un diagramme de I'application, 
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- une etape de transcription de chaque objet de chaque diagramme en une action 
correspondant a un objet dote d'attributs, chaque classe d'action ou objet 
generique etant, pendant I'etape de transcription, associe a une interface de 
saisie de donnees d'application, 

5 - une etape de transcription des noeuds, embranchements et feuilles de chaque 
diagramme en une action correspondant a un objet dote d'attributs, 

- une etape de pre-compilation au cours de laquelle on verifie que les attributs 
des objets necessaires pour la logique de fonctionnement de I'application existent 
et sont convenablement fournis, en syntaxe, 

10 - une etape de compilation au cours de laquelle les descriptifs de donnees des 
objets dotes d'attributs sont integres et sont assembles avec le logiciel systeme, 
pour obtenir un logiciel applicatif executable, et 

- une etape d'execution du logiciel applicatif executable. 

Grace a ces dispositions, le client effectue la representation du processus 

15 correspondant a I'application par une simple representation graphique en 
diagramme, qui definit integralement I'application informatique qu'il souhaite, sans 
autre contrainte que celle de connaitre le tres petit nombre d'objet generiques a 
employer. Des que cette phase est achevee, la transcription peut etre effectu6e par 
simple saisie, par une personne de faible qualification. Les deux etapes restantes, 

20 pre-compilation et compilation sont totalement automatiques. 

On observe que les descriptifs d'applications peuvent etre modifies ou 
completes aisement : une nouvelle compilation fournit un executable a jour, 
compatible avec les autres versions, et evolutif, en quelques minutes. 

On observe qu'assembler un certain nombre d'actions standards en un 

25 diagramme donne un resultat plus simple a controler que du code (par exemple du 
code "C") genere directement. Le principe est que des actions, qui travaillent sur des 
donnees convenablement organisees, peuvent §tre considerees comme sures, et 
leur contenu jamais trace, ce qui evite de longues phases de debuggage. 

Les deroulements de ces diagrammes sont fixes de fa?on permanente dans 

30 des procedures standard. II suffit de fournir les identificateurs d'ecrans et de fichiers 
utilises, et ces diagrammes vont les visualiser, modifier les menus au fur et a mesure 
des etapes, etc ... Le mecanisme de la procedure est toujours identique, mais son 
contenu est adapte, sur mesure, aux besoins exprimes par les utilisateurs. Bien 
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entendu, un certain nombre de points d'entree subsiste pour inserer des actions 
particulieres a chaque client, par exemple si le mode de lecture des donnees est tres 
particulier (par exemple, si le fichier n'est pas un fichier standard mais est importe 
d'un autre systeme, la fa9on de lire la premiere fiche n'est pas standard, done doit 
5 etre donnee par le concepteur). Par contre, le fait d'avoir le choix de demander la 
premiere fiche reste standard, done le diagramme considere est utilisable. 
L'ensemble des informations propres a chacun des applicatifs est reuni de fa9on 
structuree dans des "cartes" : le concepteur "cable" une carte pour approprier le 
processus standard a chaque processus particulier. 

10 Ce principe permet, par exemple, a une meme action de visualisation 

d'afficher des ecrans differents suivant la carte dans laquelle on se trouve, tout en 
conservant les memes parametres d'appel. II suffit d'avoir modifie auparavant une 
table de parametres indexes. 

Ce type d'interpretation est fait non pas par Taction elle-meme, mais par le 

15 mecanisme d'interpretation des diagrammes ("cablage" de la carte). En d'autres 
termes, une action comporte des donnees soit decrites de fa?on specifique soit 
decrites par des parametres (carte + numero dans la carte). 

Selon des caracteristiques particulieres, au cours de I'etape de transcription 
d'objets, au moins une action lance un traitement complet se trouvant a un endroit 

20 distant d'une arborescence correspondant audit au moins un diagramme, et une fois 
celui-ci termine, retourne & son point de depart. 

Grace a ces dispositions, les diagrammes peuvent etre constitues, modifies et 
mis a jour independamment. 

Selon des caracteristiques particulieres, au cours de I'etape d'execution, le 

25 logiciel applicatif executable met en oeuvre une bibliotheque de gestion du 
deroulement des processus correspondant audit au moins un diagramme, ladite 
bibliotheque constituant un automate qui gere le d6roulement des processus et 
execute les operations qui les jalonnent, le deroulement des operations etant defini, 
dans le referentiel applicatif, a I'aide de la methode, en decrivant les flux reels. 

30 Ainsi, la seule mise en oeuvre de la methode et de la transcription permet de 

programmer une application. 
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Selon des caracteristiques particulieres, au cours de I'etape de compilation ou 
au cours de I'etape d'execution, il met en oeuvre un moteur qui comporte un 
superviseur charge de reconnaTtre la configuration materielle et de communication. 

Grace a ces dispositions, il est inutile de generer la configuration dans 
5 I'applicatif. La gestion des echanges se fait par des taches sur I'ensemble d'un 
ecran, sur certains champs ou par des messages envoyes a Tutilisateur par le 
deroulement du processus. 

Selon des caracteristiques particulieres, le moteur gere une ou plusieurs 
bases de donnees d'apres un descriptif des fichiers de donnees fourni par le 
10 referentiel applicatif, c'est-a-dire une liste des informations contenues dans chaque 
fiche et la liste des index d'acces, avec une liste des champs servant a constituer 
chacun de ces index, les liens entre des codifications multiples d'un meme item dans 
plusieurs services, plusieurs sites ou plusieurs entreprises. 

Selon des caracteristiques particulieres, les bases de donnees sont 
15 synchronisees selon une frequence determinee par le diagramme, a la demande ou 
avant certains evenements predetermines. 

Ainsi, les bases de donnees peuvent etre synchronisees toutes les nuits, 
lorsqu'un utilisateur autorise le demande ou pour un evenement le necessitant, par 
exemple pour realiser un devis client (les stocks et les prix instantanes devant, par 
20 exemple, etre connus pour cette operations). 

Selon des caracteristiques particulieres, I'etape de transcription d'objets 
comporte, pour programmer chaque action : 

- une etape de nommage au cours de laquelle on donne un nom a ladite action, 

- une etape de definition de fonction, au cours de laquelle on met ladite action en 
25 correspondance avec une tache, et, 

- une etape de definition d'information, au cours de laquelle on designe les 
informations qui seront traitees dans Taction. 

Les actions sont enchamees suivant leur ordre fonctionnel dans des 
diagrammes. Les actions ramenant toutes a des codes definis, il est possible de 
30 representer aihsi les structures de controle classiques telles que branchement, 
boucle, test, etc ... Ces controles sont eux-memes effectues par des actions. 
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Selon des caracteristiques particuli^res, I'etape de compilation remplace le 
nom d'action donn6, au cours de I'etape de nommage, par le transcripteur, par un 
index dans une table de taches. 

Grace a ces dispositions, I'etape de transcription peut etre assez intuitive, le 
5 transcripteur choisissant un nom d'action qui lui semble aisement reconnaissable, 
tout en permettant un fonctionnement automatique et efficace de Implication 
compilee. 

D'autres avantages, buts et caracteristiques de la presente invention 
ressortiront de la description qui va suivre, faite en regard des dessins annexes dans 
10 lesquels : 

- la figure 1 represente, schematiquement, les composants du systeme objet 
de la presente invention, 

- la figure 2 represente, schematiquement, des composants mis en oeuvre par 
le procede objet de la presente invention, et 

15 - la figure 3 represente, schematiquement, les etapes mises en oeuvre par le 

procede objet de la presente invention. 

Dans la figure 1 sont representes une methode 10 de description de 
processus et de generation de diagramme 150, un generateur duplication 
informatique 20 mettant en oeuvre des objets generiques 30, des composants 

20 proceduraux 40 et des composants applicatifs 50 pour generer un logiciel executable 
60 comportant un automate 70 mettant en oeuvre les composants applicatifs 50. 

Conformement a la methode 10, methode de description cybernetique des 
processus, de quelque nature qu'ils soient, pour obtenir un descriptif sous forme de 
macro-langage, appele "referentiel applicatif, le client definit d'abord sont processus 

25 en grands ensembles, en decrivant leurs relations (par exemple gestion des stocks, 
comptabilite, decision d'organisation de travail, prise de commande, alertes 
necessaires ...). Dans un second temps, chaque ensemble est considere et 
decompose en sous-ensembles de taches, et ainsi que suite jusqu*a ce que toutes 
les actions du processus soient decrites en ne mettant en oeuvre que des 

30 diagrammes composes d'actions correspbndant, chacune a un d'objet generique de 
Tune des classes suivantes, dote d'attributs necessaires au fonctionnement des 
diagrammes : 

a) entreposage structure de dohhees, 
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b) transmission de donnees, 

c) supervision, 

d) communication avec les utilisateurs, 

e) d6roulement du processus, 

5 f) systeme operationnel (capteurs de donnees et de signaux, emission de 

messages et d'alertes), 

g) pilotage a deux niveaux (previsionnel ou operationnel). 

Le macro-langage d6fini par la methode 10 d6crit les processus pour 
constituer une couche logique, au dessus de la couche des programmes 
10 informatiques. A la base de la creation de ce macro-langage, il a ete cree une 
typologie des traitements informatiques. 

On observe que le diagramme lui-meme est compose d'une racine, 
d'embranchements, de noeuds et de feuilles, chacun de ces composants etant aussi 
represents par une action. 
15 Avec cette methode 10, le client definit les limites du probleme/processus pour 

lequel il souhaite mettre en oeuvre un logiciel executable sur mesure et ses relations 
avec I'environnement. II peut y introduire exactement ce que font les differentes 
personnes du centre de profit, les evenements exceptionnels prevus (par exemple 
les vacances de collaborateurs, les arrets d'une machine en maintenance), les aleas 
20 (par exemple une commande urgente ou une panne machine) dont il souhaite tenir 
compte et les criteres de decision d'alerte dont ils souhaitent disposer. 

Pour determiner la typologie indiquee ci-dessus, les operations repetitives 
realisees au cours du deroulement d'une application informatique ont ete recensees : 

- ces operations sont identiques, quel que soit le sujet traite, 
25 - elles sont en nombre limite, 

- elles peuvent etre reparties en sept classes (classes "a" a "g", ci-dessus) 
Chacune des sept classes d'operations est traitee selon une approche 

orientee « objet », en encapsulant les regies internes propres a la classe, regies de 
nature determinee repetitive, s'agissant du comportement d'objets informatiques (par 
30 opposition aux'objets des domaines applicatifs de gestion, soumis a Taleatoire). Les 
caracteristiques propres a chaque classe, et n§cessaires pour faire foncttonner les 
regies internes, ont ete inventoriees et reunies dans des « structures » d'atthbuts, au 
sens informatique du terme « structure ». 
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Ainsi, dans une deuxieme etape, les diagrammes representant le derouiement 
du processus de gestion ou de pilotage sont saisis en mettant en oeuvre des ecrans 
de saisie qui guident Toperateur et lui interdisent de faire certaines saisies 
incorrectes ou incompletes. Chaque objet est dote d'attributs definissant des 
5 donnees dans des formats predetermines (types de donnees, quantite, longueur et 
unite), des elements de stockage des donnees (dans des fichiers permanents et/ou 
avec une date de validite), des droits d'acces des differents utilisateurs et les 
interfaces qu'ils utiliseront, des elements de decision avec comparaison d'options 
(decision : acheter ou fabriquer, par exemple). Un support numerique permet de 
10 representer une application en remplissant les champs d'attributs dans les structures 
liees a chaque classe d'objet (par exemple, un ecran est totalement defini dans deux 
structures qui decrivent I'ensemble de I'ecran et chaque champ de I'ecran). 

Le generateur 20 effectue les operations suivantes : 

- il verifie la syntaxe, 

15 - il verifie I'existence des informations necessaires, 

- il genere la base de donnees pour I'application, et 

- il compile I'executable pour fournir une application informatique sur mesure 
Le generateur 20 effectue une pre-compilation qui verifie que les attributs 

necessaires pour la logique de fonctionnement de I'application existent et sont 

20 convenablement remplis (en syntaxe et non en contenu). 

Chaque action est associee a une interface de saisie. Cette particularity est 
un des aspects de la presente invention. La compilation accomplit ensuite 
Integration des descriptifs de donnees d'application et les assemble avec le logiciel 
systeme, pour obtenir un executable. Le logiciel systeme est permanent, commun a 

25 toutes les applications. 

L'automate 70 comporte un moteur 71 et met en oeuvre des fonctionnalites. 
Le moteur 71 repr6sente I'ordre de mise en oeuvre des fonctionnalites et les 
procedures correspondant aux diagrammes de d6roulement de I'application 
informatique. Le moteur 71 relie chaque action a Tune de ses taches types 30 (il y en 

30 a une soixantaine) au moyen de mecanismes d'execution repartis en sept classes. 

Le moteur 71 possede un ensemble predetermine et permanent de taches 
programmees informatiquement, performantes et controlees, appelees dans des 
actions applicatives. Ces actions sont executees par le coeur du moteur 71, suivant 
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un ordre defmi dans des diagrammes organises sous forme d'arborescence, avec un 
mecanisme de controle du retour des taches conduisant a la poursuite du 
diagramme en cours, ou a un branchement vers un autre diagramme ou un autre 
sous processus. Par exemple, une tache de calcul se poursuit sur la tache suivante 
5 dans le diagramme en cours, alors qu'une tache de comparaison conduit 
generalement a un branchement defini par la description de Taction appelant la tache 
de comparaisons. 

On observe que les descriptifs duplications peuvent etre modifies ou 
completes : une nouvelle compilation fournit un executable a jour, compatible avec 

10 les autres versions, et evolutif. Cependant, si on change le descriptif d'un format de 
donnees, il faut transferer les donnees dans un nouveau fichier, avec le nouveau 
format, ceci grace a une procedure automatique appartenant aux composants 
proceduraux 40. En revanche, on peut ajouter des champs, dans la limite de la place 
disponible dans le fichier, ou etendre les dimensions du fichier avec la procedure 

15 automatique evoquee ci-dessus. 

Grace a la mise en oeuvre de la pr6sente invention, on transforme une 
description procedurale en executable sans la moindre ligne de langage 
informatique. Selon un de ses aspects, la presente invention definit un macro- 
langage et/ou une nouvelle couche systeme. 

20 On comprends aisement que, lorsque le client souhaite une modification, 

on modifie le schema du diagramme et, apres traitement, il obtient un nouvel 
executable sans qu'il soit necessaire de mettre en oeuvre des competences 
d'informaticien. 

Dans les logiciels connus, le d^roulement des echanges entre le logiciel et les 
25 utilisateurs est conduit par le systeme graphique. lei, e'est le logiciel qui a la maitrise 
du deroulement des operations, y compris avec le systeme graphique. On obtient 
ainsi I'independance par rapport aux systemes externes, la possibility de 
communiquer indifferemment avec differentes interfaces, par identification de 
I'interlocuteur. 

30 Le moteur 71 execute les operations du processus d'une fafon neutre et 

independante du domaine d'application, grace a des mecanismes d*execution issus 
d'une typologie rigoureuse des modes de fonctionnement de I'informatique et repartis 
en sept classes. 
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On observe que, dans la douzaine de structures utilis6es (structure au sens 
informatique du terme), trois sont des structures dynamiques, une est une structure 
de navigation et les autres sont des structures descriptives de donnees. 

Des objets proceduraux applicatifs repetrtifs et communs a tous types 
5 d'application sont utilises : saisie de fiche simple, saisie de fiche avec liste attachee 
(par exemple les mouvements de stock pour un produit), impression, alerte, 
reconfiguration de fichiers de donnees, liaisons avec d'autres systemes d'information. 
S'y rattachent un mecanisme de deroulement et un superviseur qui constituent le 
"coeur" du moteur 71 . 

10 On va maintenant decrire d'autres objets mis en oeuvre conformement a la 

presente invention. 
1/ Les donnees (ou "rubriques") 

- nom de la donnee 

- type alphanumerique, nombre 
15 - taille 

- cadrage 

- nombre de decimales et signe (si donnee numerique) 

On observe qu'une rubrique est definie une seule fois pour une application et peut 
etre appelee dans tout fichier ou interface de cette application. Une rubrique porte le 
20 meme nom dans toutes les applications, mais sa description est adaptee aux 
besoins de chaque applicatif : automatiquement les fichiers, interfaces et traitements 
disposent des specifications propres a I'application. 
21 Les fichiers de donnees (ou tables) 

- le nombre de donnees dans le fichier et la dimension de I'espace sur disque 
25 ou en memoire pour la gestion de chaque fiche, 

- la description des donnees de chaque enregistrement du fichier et leurs liens 
avec des donnees d'autres fichiers ou ecrans 

o nom de la rubrique, 
o liens avec d'autres fichiers ou ecrans 
30 3/ Les interfaces utilisateurs (ecrans) 

- le nombre de donnees dans I'ecran et la dimension de I'espace de gestion de 
I'ecran 
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- la description de chaque donn6e de I'ecran fichier, de son comportement dans 
les echanges a travers 1'interface homme-machine et ses liens avec des 
donnees d'autres fichiers ou ecrans : 

o nom de la rubrique, 

o liens avec d'autres fichiers ou ecrans, 

o type d'objet interface homme machine : libelle, texte, boutons radio, ... 
o positionnement sur I'ecran, 

o mode de saisie : en mode creation de cle (mode d'acces au fichier, par 
exemple par nom ou par localisation) ou de selection, en mode courant 
(dans lequel on ne modifie plus de cle, sauf si elle est modifiable), 

o traitements lies 3 la donnee, en debut et en fin de saisie (a fin de 
controle, de traitements, ...), 

o champ sur lequel retourner en cas d'erreur 
4/ Les espaces de gestion dynamique des fichiers et ecrans, lors de leur utilisation 

- dimension des espaces, 

- valeur des donnees de la fiche ou de T6cran en cours d'usage (identification 
des donnees, quantit6s, montants, ...), 

- etats des traitements (phases de recherche d'une fiche, de traitements de la 
fiche, de validation de fiche), 

5/ Un navigateur, tra?ant pour chaque utilisateur, la route suivie au cours du 
deroulement de son travail et assistant une hyper-navigation par la possibility 
d'atteindre directement des processus distants, puis de revenir au processus en 
cours : 

- etapes du parcours, 

- travaux realises au cours de Petape, avec un tra^age des liens avec les 
processus distants, assorti d'un mecanisme de retour automatique en arriere, 

6/ Des diagrammes de flux 

- description de diagrammes de traitements, avec des branchements soit 
choisis par I'utilisateur (par exemple par utilisation de menus), soit imposes 
par la logique du contexte (aiguillage sur deux processus differents de calcul 
d'un prix de revient suivant le caractere achet6 ou fabrique d'un produit), 

r 
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- sur chaque branche, appel a des actions de traitement : calcul, affectation de 
valeurs a des donnees, comparisons, interface avec des fichiers ou des 
ecrans, ... 

7/ Des messages et menus 
5 - messages d'information, 

- messages d'alerte, 

- choix de traitements par des menus 

D'une maniere generate, la presente invention vise un systeme logiciel 
composite associant : 
10 1/ un moteur 71 capable de realiser de fagon standard et en temps reel : 

- des procedures de traitement d'informations de toutes natures, soit en 
simulation d'hypotheses futures, soit en mettant en oeuvre les evenements 
reels, 

- sous forme d'ensembles et sous-ensembles de traitements, coordonnes et 
15 possedant des capacites de boucles de feed-back fournissant et/ou 

echangeant des informations en retour, 

- avec la mise a disposition de tableaux de bord permanents et le 
declenchement de signaux d'alerte presentes instantanement ou en temps 
utile aux utilisateurs concernes (on definit done qui doit etre alerte et quand, 

20 dans le diagramme). 

21 un referentiel applicatif, cree a I'aide de la methode 10, decrivant les informations 
et leurs traitements specifiques et repondant exactement aux besoins de I'entreprise 
et des utilisateurs : 

- pour un processus de gestion, ou un ensemble de processus en interrelation, 
25 - sous une forme de systeme et sous-systemes avec des boucles de feed-back, 

- avec une description sous forme banale et non informatique des flux r6els, si 
necessaire amenages pour plus de performances et de reactivite des acteurs 
et du systeme dans son ensemble. 

3/ un g6n6rateur 20 de logiciel executable sur mesure : 
30 - le logiciel executable est g6nere sans programmation, en associant le moteur 
71 (paragraphe 1) et le referentiel (paragraphe 2) de I'applicatif, 

- la description sur mesure des besoins exprimes dans le r6f6rentiel est traduite 
automatiquement dans le langage du moteur 71 
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- le generateur de logiciel executable est lui-meme construit avec le moteur 71 
standard avec son propre referentiel applicatif. 

D'une maniere plus detaillee, le moteur 71 est un ensemble de bibliotheques 
de fonctions C, java et Internet, permettant une gestion de processus, simples ou 
5 complexes, avec : 

- un traitement en temps reel des evenements et des informations qui leur sont 
liees, 

- la detection de situations anormales accompagnees d'un systeme de signaux 
d'alerte, 

10 - ('identification complete des evenements avec un stockage des donnees sous 
forme d'une base de connaissances a jour en permanence. 
Chaque bibliotheque est specialisee dans un domaine particulier, et liee aux 
autres dans un schema de relations fonctionnelles. Les fonctionnalites et donnees 
utilisees dans chaque bibliotheque sont formalisees dans un langage et avec une 
15 syntaxe propre au moteur 71 . 

La bibliotheque de gestion du deroulement des processus constitue 
('automate 70 qui gere le deroulement des processus et execute les operations qui 
les jalonnent. Le deroulement des operations est defini dans le referentiel applicatif, 
a I'aide de la methode 10, en decrivant les flux reels, si necessaire amenages pour 
20 plus de performances et de reactivite, des la conception et facilement adaptables 
lorsque ['organisation change dans le temps. 

Les processus sont structures sous forme d'arborescences de flux 
operationnels. Ces arborescences represented les flux du reel, tels qu'ils ont ete 
analyses avec les utilisateurs a I'aide de la methode 10. Le moteur 71 execute 
25 I'enchainement des operations sur chaque branche du flux en cours de traitement. 
Des branchements sont declenches : 

- soit par un choix de I'utilisateur a Taide d'un menu, 

- soit par evaluation de la situation conditionnant les etapes suivantes : 

o choix d'une branche parmi plusieurs pour poursuivre le processus, 
30 o rriise en oeuvre de signaux d'alerte et de boucles de feed-back 

(asservissement) 

Chaque processus est jalonn6 d'op6rations ou actions. Le moteur 71 execute 
la suite de ces actions en faisant appel a une bibliotheque de taches. 
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Les taches utilisees, illustrees en figure 2, associees au deroulement des flux 
de la realite, sont de cinq types : 

a) taches complexes 21 d'appel a d'autres processus ou sous-processus, 

b) taches complexes d'aiguillage 22, 

c) taches simples 23 de calculs, de traitements d'informations, 

d) taches de communication et d'echanges 24 avec les utilisateurs, 

e) taches de transactions 25 avec des bases de donnees. 
Chacun de ces cinq types va etre decrit ci-dessous. 

a) Taches complexes 21 1 d'appel a d'autres processus ou sous-processus 

- ces taches lancent des applications, sous forme d'un nom de processus, 
chaque processus etant assorti de droits d'acces ; 

- chaque personne ayant un code d'acces regoit 

o I'attribution d'un processus initial par lequel elle entre dans le systeme, 
o une definition de ses droits qui guident ses acces a d'autres processus 
en cours de navigation, 

- les taches d'appel a des processus permettent soit d'acceder a des 
« briques » fonctionnelles communes, soit de pratiquer une « hyper 
navigation » entre des fonctions et processus differents. 

o Le branchement sur un autre processus se termine par le retour 
automatique sur le processus en cours (hyper-navigation) 

- les « taches d'appel de processus » permettent de rendre tres simple et 
souple ('utilisation commune de processus et de declencher quatre types de 
processus : 

o un sous-processus 211 faisant suite au processus en cours, 
o un processus distant 212, 

o un sous-processus standard 213, commun a plusieurs processus, 
o un applicatif generique complexe 214, commun a toutes les 
transactions avec les utilisateurs 
Un sous-processus 21 1 se declenche & la suite d'un aiguillage issu d'un choix 
de I'utilisateur par utilisation d'un menu (le sous-processus a le nom du processus 
origine, complete du num6ro du choix dans le menu) ou d'une evaluation de la 
situation (le referentiel applicatif peut soit donner un nom specifique au sous- 
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processus, soit conserver le nom du processus origine, en le completant d'une lettre 
(par exemple un « e » en cas de detection et de traitement d'une erreur). 

Par un processus distant 212, I'utilisateur evite un parcours difficile a travers 
des suites de menus. L'utilisateur accede directement a des taches annexes par une 
5 « hyper navigation ». Quand un processus distant 212 se termine, la navigation 
ramene au processus appelant. Ce mecanisme de processus distants permet de 
partager sans difficultes un processus entre plusieurs utilisateurs, services ou 
fonctions. Par exemple, la prise de commande peut se faire par un commercial 
eloigne ou proche, aussi bien que par un service d'administration des ventes local. 

10 Un sous processus standard 213 correspond a une procedure elementaire 

totalement repetitive et commune a plusieurs processus. Ces processus standards 
213 peuvent etre definis pour une entreprise, compte tenu de ses besoins 
particuliers, pour un ensemble d'entreprises, auxquelles s'imposent les memes 
logiques ou regies de base. Par exemple, un calcul de stock reel ou previsionnel 

15 peut etre realise au magasin, aux achats, dans un calcul automatique de sortie de 
stock, lors d'un ajustement d'inventaire. 

Un applicatif generique complexe 214 est commun a toutes les transactions 
realisees par les utilisateurs. II fait partie des fonctionnalites offertes par le procede 
objet de invention : 

20 - saisie simple, par exemple saisie ou mise a jour d'une fiche client, d'une fiche 
produit, 

- saisie de liste, par exemple saisie ou mise a jour d'une fiche nomenclature 
(liste des composants attaches a une nomenclature), 

- declenchement d'alerte dans les processus de pilotage, par exemple 
25 d6passement de delai, ecart anormal entre budget previsionnel et realise, 

- impression, par exemple, impression de certaines donnees clients : un client, 
une categorie de clients, la totalite du fichier client (liste des clients avec leurs 
adresses, ou leurs chiffres d'affaires, leurs commandes en cours, ...). 
Taches complexes d'aiguillage 22. A chaque noeud de Tarborescence, les 

30 aiguillages entre plusieurs branchements sont declenches par trois voies : un choix 
221 de l'utilisateur, par une navigation avec un menu, une identification d'une 
situation precise 222 comportant plusieurs possibilites de traitement (par exemple, 
dans le calcul de prix de revient d'un produit £ partir de sa nomenclature, les calculs 
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du cout d'un produit achet§ et celui d'un produit fabrique sont differents et donnent 
lieu a des sous-processus differents), une evaluation d'une situation 223 sur la base 
de criteres de controle avec declenchement d'alertes, de boucles de feed-back (par 
exemple couts ou delais anormaux). 
5 Les taches simples 23 de calculs ou de traitements d'information se 

caracterisent par le fait qu'elles seules traitent directement les informations. Le 
procede de I'invention inclut les informations utiles a la conduite et a la maTtrise des 
flux et prevoit le pilotage et I'aide a la decision operationnelle. Le dispositif utilise des 
capteurs et des regies de controle au plus pres des evenements. Le processus 

10 recueille les informations des qu'un ev6nement survient, en temps reel, et dedenche 
en tant que de besoin des signaux d'alerte aupres des personnes chargees des 
decisions operationnelles, dans les delais utiles (definis par le diagramme) pour 
chacune d'elles (immediat pour les decisions d'execution, ou avec un delai approprie 
a la bonne efficacite des decisions de gestion). 

15 Les calculs 231 comportent les operations de base, avec prise en compte du 

nombre de decimales, les cumuls et ventilations et I'attribution de valeurs 
alphabetiques ou numeriques. 

Les comparaisons 232 sont effectuees entre des donnees alphabetiques ou 
numeriques. D'apres le resultat d'une comparaison, on dedenche des branches de 

20 traitement appropriees. 

L'envoi de message 233 est effectue vers I'utilisateur ou vers d'autres 
utilisateurs (alerte), en fonction de resultats constates a un poste. 

Les transferts 234 sont relatifs a des liens entre des champs d'un ecran ou 
d'un fichier avec des champs d'autres ecrans ou fichiers, soit en importation, soit en 

25 exportation. Un transfert ponctuel peut aussi etre effectue entre des champs d'origine 
et des champs de destination. 

Le traitement de dates 235 concerne Tattribution de la date et de I'heure 
« systeme », le calcul de dates de debut et de fin d'operations d'apres un ddlai ou 
calcul d'un d6lai d'apres des dates de debut et de fin, et la comparaison de dates. 

30 Les taclies de communication et d'echange 24 avec les utilisateurs se font par 

I'interm6diaire d'un terminal informatique, soit a travers un reseau classique, soit par 
un navigateur internet. Le moteur 71 comporte un superviseur charge de reconnaftre 
la configuration materielle et de communication (r6seau local, intranet, internet, ...) 
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de I'utilisateur, et il est done inutile de generer celle-ci dans I'applicatif. La gestion 
des echanges se fait par des taches sur I'ensemble d'un ecran, sur certains champs 
ou par des messages envoyes a I'utilisateur par le deroulement du processus. 
Les taches de communication et d'echange 24 comportent : 

- la creation et destruction d'un ecran (activation de I'ecran et affectation de 
memoire) 241, 

I'affichage d'une page complete 242, avec son titre, ses libelles et ses champs 
d'information puis effacement de la page, 

- I'affichage d'informations dans des champs 243 et modification d'ecran, y 
compris affichage de I'ensemble des informations (par exemple a la lecture 
d'une fiche), I'affichage de champs modifies (par exemple a la suite de calculs 
declenches par la saisie d'un champ et influen?ant d'autres champs, 
attribution de valeur dans un bouton radio, ...) 

- la gestion des autorisations de modification 244, sur les constituant des codes 
ou noms servant a lire des fiches sur la base de donnees (acces en mode de 
selection, champs de cles modifiables ou non), ou sur les informations 
courantes de la page d'6cran (acces en mode de mise a jour, acces en simple 
consultation ou champ sans objet contextuel), 

- le positionnement particulier sur un champ 245, y compris champ obligatoire a 
remplir et champs a corriger en cas d'erreur de saisie reconnue, 

- renvoi de message 246, y compris information a I'utilisateur, en particulier en 
cas d'erreur, I'affichage d'une boite de dialogue a acquitter avant reprise de la 
saisie d'6cran, ou I'affichage d'un message d'information durable en bas de 
I'ecran, 

- I'effacement de I'ecran 247, y compris passage provisoire a un autre ecran et, 
en fin d'utilisation d'un ecran, avant sa destruction. 

On observe que le dessin des ecrans est adapte a chaque categorie 
d'utilisateurs, en fonction des besoins de chacun. Leur simple description dans le 
referentiel applicatif suffit a faire fonctionner les taches de gestion des echanges 
indiques ci-dessus. II est facile et rapide de les adapter en tant que de besoin, par 
simple modification de leur descriptif. Les informations sont presentees sous forme 
d'objets graphiques et specifiees comme telles (champ de saisie ordinaire, boutons 
« base de donnees », boutons radio verticaux ou horizontaux, cases a cocher, 



WO 03/085521 PCT/FR03/01019 

17 

languettes, editeur, table, code a barres, libelle, lien hypertexte). Les champs 
d'informations sont accessibles en mise a jour, accessibles seulement en 
consultation ou invisibles a destination par exemple de champs d'identificateurs, de 
champs intermediates de calculs, ou de champs d'informations elaborees a 
5 destination de tableaux de bord distants. 

Concernant les droits d'acces, tout acces aux processus est soumis a un 
controle des droits de la personne en ligne. Chaque personne accedant a I'applicatif 
ne peut « voir », modifier, que ce qui lui est attribue par les droits qu'elle a re?u avec 
son code d'acces. Ces droits peuvent changer dans le temps, sous la responsabilite 
10 d'un gestionnaire des acces. Une personne ayant des droits eleves a interet a 
recevoir plusieurs codes d'acces avec des droits de plusieurs niveaux, afin de limiter 
les risques d'acces intempestifs, par d'autres personnes, a des informations 
confidentielles. 

La presentation des documents imprimis est consideree comme celle d'un 
15 ecran, avec la limite d'un acces a consultation, avec la possibility de disposer de 
dimensions de « pages » plus grandes. 

Les taches de transaction avec des bases de donnees 25 comportent : 
Tinitialisation et la liberation des espaces d'informations lies a un fichier 251, 
- la creation ou la mise a jour de fiches 252 par ecriture sur la base destinataire 
20 (chaque fiche report automatiquement un numero d'identification univoque qui 

sert de lien entre des items apparentes, sans que des modifications de code 
ou d'appellation aient une quelconque consequence, 

la creation de cles d'acces pour lecture de fiche particuliere 253 : acces 
possible par des codes, des noms, des periodes de validite, des liens avec 

25 d'autres fiches, ... (I'acces a la base de donnees en multi-codification permet 

de rendre les informations accessibles a chaque categorie d'utilisateurs en 
respectant sa culture propre, par exemple les codes produits sont souvent 
differents pour la technique et pour le commercial, voire entre plusieurs 
etablissements; entre plusieurs processus autonomes (exemple : liaisons 

30 entre les differents services fournis par une banque A un meme client). 

la lecture d'une fiche 254 (la fiche est lue sur une ou plusieurs cles d'acces a 
preciser : code, nom, identificateur, ... 
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- la lecture d'une liste de fiches ayant un rattachement commun 255 (par 
exemple les mouvements de stocks rattaches a un produit, composants d'un 
produit, lignes de commande, liste des commandes en cours pour un client, 
liste des commandes pour un produit), 

5 - la suppression d'une fiche 256, selon des modalites de controle 
predetermines (par exemple, ne pas supprimer une fiche produit si elle 
possede un stock ou si une ligne de commande en cours y est rattachee), 

- le parcours d'un fichier pour operer un traitement systematique sur toutes les 
fiches, sur un ensemble de fiches entre deux bornes, ou sur des fiches ayant 

10 une meme racine (par exemple, impression de tout ou partie d'un fichier, 

valorisation de marges sur toutes les commandes d'un meme client, d'un 
agent commercial, d'une region, ... 

Le moteur 71 gere la ou les bases de donnees d'apres le descriptif des 
fichiers de donnees fourni par le referentiel applicatif, c'est-a-dire la liste des 

15 informations contenues dans chaque fiche et la liste des index d'acces, avec la liste 
des champs servant a constituer chacun de ces index, les liens entre des 
codifications multiples d'un meme item dans plusieurs services (commercial et 
technique), plusieurs sites ou plusieurs entreprises (clients - fournisseurs, societes 
fusionnees, ...), les bases de donnees etant alors synchronises selon une 

20 frequence determinee par le diagramme ou a la demande ou avant certains 
evenements (par exemple pour realiser un devis client). 

On observe, concernant 1'evolution du referentiel applicatif dans le temps, que, 
dans certaines limites de dimensions de chaque fiche, controlees par le moteur 71 , il 
est possible de completer les informations contenues dans un fichier. Si les formats 

25 des informations utilisees dans I'entreprise se modifient dans le temps, il est ais6 de 
maintenir les donnees acquises dans le passe par une procedure systeme du moteur 
71. 

La biblioth^que de liaison 26 est partagee entre le referentiel applicatif et le 
moteur 71. Les informations necessaires a I'execution des taches doivent etre 
30 specifiees en tant que de besoin et le moteur 71 les rattache a sept types : 

a) menus et choix 261 , 

b) messages et alertes 262, 

c) champs d'information et format de donnees 263, 
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d) designations des informations 264, 

e) fichiers 265, 

f) interfaces visuelles 266, ecrans ou pages internet, 

g) branches de processus et taches 267. 

5 Les menus et choix 261. Les taches d'aiguillage declenchees par les 

utilisateurs comportent des informations de type « menus et choix ». Les utilisateurs 
se voient proposer un menu a chaque fois que leur intervention est necessaire pour 
choisir entre plusieurs sous-processus et poursuivre la navigation. Le procede 
nomme « choix » chacun des elements du menu. A chaque choix est lie une branche 
10 du processus. Chacune des branches est dotee d un code d'acces : si I'utilisateur ne 
possede pas les droits necessaires, le menu filtre et ne propose par le choix 
correspondant.. 

Les messages et alertes 262. Le procede nomme « messages » les echanges 
declenches au cours de transactions avec un utilisateur. Le proc6de envoie, 

15 exclusivement a I'utilisateur, des messages d'information pour faciliter sa tache et 
des messages d'anomalie et d'erreur lorsque celles-ci sont detectees. Le procede 
nomme « alerte » renvoi d'informations de pilotage a tous les utilisateurs concernes 
lorsqu'il detecte des anomalies, au cours d'un processus. Les alertes, envoyees a 
distance, sont d'une autre nature que les messages et sont rattachees a la 

20 procedure standard de gestion des alertes. Les taches d'echanges et de 
communication avec les utilisateurs se font en temps reel. 

Les champs d'information 263. Chaque element d'une liste d'informations 
dans un fichier et dans une interface visuelle est nomme un « champ ». Pour les 
champs d'un fichier, la specification du format de chaque information indique la taille 

25 de reformation et reserve en cons6quence la place necessaire pour les stocker sur 
disque. Lors de la generation du logiciel, la base de donnees est automatiquement 
creee ou mise a jour. Pour les champs d'un ecran, d'une page internet ou d'un 
imprime, leur presentation peut etre faite suivant la demande de I'utilisateur et 
changee aisement. 

30 Chaque' champ possede un nom et un format. Chaque entreprise utilise un 

ensemble de donnees de base : references techniques et commerciales des 
produits, prix unitaires, montant d'une facture, temps, couts, delais d'une commande, 
chiffre d'affaire hors taxes et toutes taxes comprises, ... 
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Le procede nomme « format des donnees », la specification du format de 
chacune de ces donnees. Ce format des donnees est utilise pour reserver la place 
necessaire dans les fichiers, pour afficher correctement les informations et pour 
controler la saisie des informations. L'attribution d'un format a une information 
5 specifie sa presentation et sa dimension : type attribue (donnee alphanumerique, 
code numerique, nombre, date, ...), description (nombre de caractere, cadrage, 
presence eventuelle d'un signe, nombre de chiffres de la partie entiere et nombre de 
decimales, numero du mois inferieur ou egale a 12, numero de la semaine inferieur 
ou egal a 54, jour dans le mois inferieur ou 6gal a 31, heure inferieure ou 6gale a 24, 
10 ... 

Le procede gere une codification multiple (multi-codification) pour tenir compte 
de references differentes pour un meme objet, par exemple references techniques et 
commerciales, liens entre processus distincts, references differentes entre plusieurs 
sites ou societes appartenant au meme groupe, ou plusieurs entreprises liees 

15 economiquement (clients - fournisseurs, societes fusionn6es, ...). 

Designation des informations 264. Le procede identifie par une designation les 
informations presentees sur les supports de communication avec les utilisateurs. 
Chaque information d'une interface est presentee avec une designation. Plusieurs 
designations peuvent etre utilisees pour tenir compte des differences de langue ou 

20 de fonction des utilisateurs. 

Fichiers 265. Le procede definit la structure des informations dans les fichiers 
et I'organisation de leur stockage en base de donnees. Les fichiers recueillent des 
ensembles d'informations structurees. Une fiche est une structure de fichier (par 
exemple fiche-client) comporte une liste d'informations definies par un nom et un 

25 format. Chaque fiche d'un fichier peut etre atteinte par plusieurs cles d'acces 
differentes suivant la preoccupation de Tutilisateur, ou son besoin immediat. Les 
evenements sont identifies en temps reel avec des etiquettes appropriees a la 
situation vecue. La base de donnees constitue une base de connaissances en 
permanence £ jour. 

30 Interfaces visuelles 266, ecrans ou pages internet. Le proced6 definit 

I'organisation des informations pour leur presentation aux utilisateurs. Les interfaces 
visuelles represented un ensemble d'informations qui sont affichees avec leur 
designation sur un 6cran d'ordinateur, une page internet, un imprim6. Comme pour 
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les fichiers, une Interface visuelle comporte une liste conformations definies par un 
nom et un format, ainsi qu'un Jien avec les donnees correspondantes stockees dans 
les fichiers. Chaque information est dotee d'attributs precisant leur presentation 
visuelle, leur mode de traitement ou de saisie. Les interfaces visuelles peuvent etre 
5 presentees sous une forme appropriee a chaque utilisateur, et modifiees pour 
repondre a de nouveaux utilisateurs ou de nouveaux besoins. 

Branches de processus et taches 267. Chaque branche de processus est 
representee dans un diagramme et reflete la description des flux reels, obtenue avec 
le referentiel applicatif : nom du processus, enchainement des operations, noeuds de 

10 branchements, droits d'acces au processus (services, postes agrees). Chacune des 
operations doit etre decrite : nom de I'operation, nom de la tache du moteur 71 qui 
devra etre executee, parametres de I'operation, suivant la syntaxe determinee pour 
chacune des taches existantes. 
Le referentiel applicatif. 

15 Ce referentiel est cree en association avec les utilisateurs concernes par le 

processus a informatiser, d'apres la situation existante, et en etudiant d'eventuelles 
ameliorations, facilities par I'emploi d'un outil informatique. Une fois I'accord des 
utilisateurs obtenu, le referentiel est numerise (par exemple, par saisie ou par lecture 
optique ou sonore), en vue d'obtenir une importation automatique dans le logiciel 

20 executable. 

Generateur de logiciel executable sur mesure 20. Ce generateur utilise les 
donnees du referentiel applicatif, transcribes sous forme numerique. Le generateur 20 
precede en deux etapes : 

- importation 361 (voir figure 3) des donnees du referentiel dans une base de 
25 donnees interne, et 

- generation 362 (voir figure 3) du logiciel executable. 

On observe, en figure 3, que la mise en oeuvre d'un mode particulier de 
realisation du procede objet de la presente invention comporte le mise en oeuvre 
d'un logiciel systeme commun a tous les logiciels applicatifs et : 
30 - une etape d'initialisation 31 d'un systeme informatique, 

- une etape de repr6sentation 32 du processus, mettanf en oeuvre un tres petit 
nombre de classes d'actions ou objets gen6riques, typiquement inferieur a vingt, 
dans au moins un diagramme de I'application, 
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- une etape de transcription 33 de chaque objet de chaque diagramme en une 
action correspondant a un objet dote d'attributs, chaque classe d'action ou objet 
generique etant associe a une interface de saisie de donnees d'application, 
comportant, pour programmer chaque action : 

5 i) une etape de nommage 331 au cours de laquelle on donne un nom a ladite 

action, 

ii) une etape de definition de fonction 332, au cours de laquelle on met ladite 
action en correspondance avec une tache, et, 

iii) une etape de definition d'information 333, au cours de laquelle on designe 
10 les informations qui seront traitees dans Taction. 

- une etape de transcription 34 des noeuds, embranchements et feuilles de 
chaque diagramme en une action correspondant a un objet dote d'attributs, 

- une etape de pre-compilation 35 au cours de laquelle on verifie que les attributs 
des objets necessaires pour la logique de fonctionnement de I'application existent 

15 et sont convenablement fournis, en syntaxe, 

- une etape de compilation 36 au cours de laquelle les descriptifs de donnees des 
objets dotes d'attributs sont integres et sont assembles avec le logiciel systeme, 
pour obtenir un logiciel applicatif executable, et 

- une etape d'execution 37 du logiciel applicatif executable compile au cours de 
20 I'etape de compilation 36. 

Au cours de I'etape de transcription d'objets, une ou plusieurs action(s) 
lance(nt) un traitement complet se trouvant a un endroit distant d'une arborescence 
correspondant audit au moins un diagramme, et une fois celui-ci termine, retourne a 
son point de depart. 

25 Preferentiellement, au cours de l'6tape d'execution, le logiciel applicatif 

executable met en oeuvre une bibliotheque de gestion du deroulement des 
processus correspondant audit au moins un diagramme, ladite bibliotheque 
constituant un automate 70 qui gere le deroulement des processus et execute les 
operations qui les jalonnent, le deroulement des operations etant defini, dans le 

30 referentiel applicatif, a I'aide de la methode 10, en decrivant les flux reels. 

Preferentiellement, au cours de l'6tape de compilation ou au cours de Tetape 
d'execution, il met en oeuvre le moteur 71 qui comporte un superviseur charge de 
reconnaitre la configuration mat6rielle et de communication. Preferentiellement, le 
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moteur 71 gere une ou plusieurs bases de donnees d'apres un descriptif des fichiers 
de donnees fourni par le referentiel applicatif, c'est-a-dire une liste des informations 
contenues dans chaque fiche et la liste des index d'acces, avec une liste des 
champs servant a constituer chacun de ces index, les liens entre des codifications 
5 multiples d'un meme item dans plusieurs services, plusieurs sites ou plusieurs 
entreprises. Les bases de donnees sont synchronises selon une frequence 
determinee par le diagramme, a la demande ou avant certains evenements 
predetermines. 

Preferentiellement, I'etape de compilation (36) remplace le nom d'action donne 
10 par le transcripteur, au cours de I'etape 33, par un index dans une table de taches. 

Preferentiellement, au cours des etapes de representation et de transcription, 
(edit au moins un diagramme correspond 3 au moins une arborescence dans laquelle 
les noeuds et feuilles, ou le code est effectue, sont composes d'actions, les valeurs 
de retour de ces actions determinant le deplacement dans I'arborescence. 
15 Une fois terminee la generation, le procede peut passer sur Tapplicatif de 

I'entreprise, chaque processus de I'entreprise etant accessible suivant les droits des 
utilisateurs. 

Le referentiel applicatif peut etre modifie. Une nouvelle generation du logiciel 
executable met a la disposition des utilisateurs la nouvelle version. Le temps 
20 necessaire a une generation est de I'ordre de dix a trente minutes, suivant 
Timportance du processus. 

Etape d'importation 361 des donnees du referentiel dans une base de 
donnees interne. Au cours de cette phase, le generateur 20 controle la synthaxe et la 
coherence des donnees fournies par le descriptif de I'application. La presence de 
25 certaines donnees de description obligatoires est controlee. Les donnees appelees 
dans les traitements doivent exister : champs d'informations, libelles, messages, 
processus, taches. Si le generateur 20 d6tecte une erreur, il envoie un message et 
refuse de passer a la phase suivante. 

Etape de generation 362. Une fois le referentiel applicatif accepte, le 
30 generateur 20 genere le logiciel applicatif en associant le moteur 71 et les donn6es 
applicatives. La fin de cette phase de g§neration 362 redonne la main & I'utilisateur, 
avec la nouvelle version disponible en cas de changements. 
On definit deux classes de structures : 



WO 03/085521 PCT7FR03/01019 

24 

* 

- celles qui servent 3 decrire ies informations utilisees dans les applications, 
particulierement le format des donnees, la structure des enregistrements dans 
la base de donnees et la fapon dont Ies ecrans sont presentes, et 

- celles qui correspondent a la fagon dont le programme va se derouler (I'ordre 
5 dans lequel les traitements vont etre effectues) : diagramme de flux ou de 

processus et actions sur les flux. 

Les premieres sont des donnees de description et les secondes des donnees 
de deroulement. 

Les donnees de deroulement comportent : 
10 a/ les actions 

Les donnees de deroulement ont une organisation particuliere qui a une forte 
incidence sur la fa?on de programmer les applications. Une des motivations est 
d'eviter la programmation directe en langage informatique, par exemple en langage 
C. A cet effet, un certain nombre de fonctions de manipulation et de presentation des 
15 donnees ont ete definies. Leur ont ete associees un certain nombre d'arguments, 
fixes ou pouvant etre parametres grace a certaines structures de donnees (les 
« cartes » decrites plus loin) et d'empaqueter le tout dans un ensemble identifie par 
un code. Chaque ensemble porte le nom d' « action ». La structure action est donnee 
ci-dessous : 
20 struct action 

{ 

char *ac__name; 
int *ac_fonc 
unsigned long ac_param[MPRM]; 
25 char *ac_article; 

} 

Programmer une action, dans cet esprit, revient simplement a lui donner un 
nom, affecter la "tache moteur" ou "tache type" (par exemple : calcul, comparaison, 
contr6le, branchements, ...) et designer les informations qui seront traitees dans 
30 Taction. 

Les actions sont enchaTnees suivant leur ordre fonctionnel dans des 
diagrammes. Les actions ramenant toutes a des codes definis, il est possible de 
representer ainsi les structures de contrdle classiques telles que branchement, 
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boucle, test, etc ... Ces controles sont eux-memes effectues par des actions, voir 
plus loin. Deroulement du code dans I'application - Diagrammes de processus. 

Le concept sur lequel le deroulement est base, intimement lie a celui d'action, 
est celui d'arborescence. Ce n'est pas une idee nouvelle qu'une application a base 
5 de menus soit structuree en forme d'arborescence. Dans notre cas cependant, le 
diagramme a ceci de particulier que ses noeuds et feuilles, ou le code est effectue, 
sont composes d'actions. En fait, chaque noeud est un receptacle ou peuvent tenir 
MACT actions - Le nombre d'actions dans une branche, MACT, est un parametre du 
moteur 71. Les valeurs de retour fournies par ces actions, determinent le 
10 deplacement dans les arborescences. 

On observe qu'assembler un certain nombre d'actions standards en des 
diagrammes donne un resultat plus simple a controler que du code C genere 
directement. Le principe etant que des actions, supposees travailler sur des donnees 
convenablement encapsulees, sont considerees comme sures, et leur contenu n'a 
1 5 jamais a etre trace. 

Implementation des diagrammes. 

Les noms des diagrammes et les actions jalonnant les diagrammes sont 
places dans une structure appelee struct branche. La structure branche est decrite 
ci-dessous : 
20 typedef struct branche 

{ 

char nom_digramme[LNOM]; 
unsigned int table_traitements[MACT]; 
char *securite ; 

25 } node; 

Le nom M nom_diagramme M permet d'identifier le diagramme et de se deplacer 
de diagramme en diagramme. Les 6l6ments de table_traitements sont des actions 
qui seront ex6cutees a I'arriv6e sur le diagramme; le concepteur leur donne un nom 
et la compilation remplace ces noms par des index des actions dans une table qui 
30 les regroupe : feur acces est instantane et permet d'obtenir de bonnes performances 
des traitements informatiques. 

La chaine de caracteres "securite" est examinee avant toute demande 
d'arriv6e sur le diagramme, pour permettre d'interdire I'acces en fonction des droits 
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de Tutilisateur de Tapplication. C'est ainsi que certains menus ne seront pas visibles 
pour certains utilisateurs, et visibles pour d'autres. 

On decrit ci-dessous, sur un exemple, la fagon dont on se deplace dans les 
noeuds et dont on execute le code. 
5 Supposons que le nom du diagramme courant soit « L ». 

En arrivant sur ce diagramme, le systeme execute Taction tab_tr[0]. Si elle 
ramene le code NEXT, comme le font, par exemple les 4 premieres actions du 
diagramme L11, on execute Taction suivante. Si elle ramene DSCD (pour 
« descend »), elle doit aussi avoir positionne une variable globale, Choix. Cette 

10 variable va alors etre concatenee au nom du diagramme courant, pour donner le 
nom du nouveau diagramme. Par exemple, si la variable choix vaut « 1 », on se 
dirige vers le diagramme « L1 ». On note DSCD(1) Tassociation de DSCD et de 
choix=1. L'inverse de la procedure se produit si une action retourne RMTE. Dans ce 
cas, Taction doit avoir positionne certains drapeaux (« flags ») internes pour 

15 determiner a quelle action de la branche de remontee on reprend le traitement. Par 
exemple, une remontee a Taction 3 depuis L1 nous positionne sur la quatrieme 
action du nceud L (les actions etant numerotees £ partir de 0.) 

Plus precisement, c'est le caractere ASCII representant le nombre choisi qui 
est additionne. II faut done eviter de donner a "Choix" une valeur en dehors de 

20 Tintervalle [a-zA-Z-0-9], afin d'eviter les caracteres invisibles ou dotes de 
fonctionnalites dans la table ASCII. 

On peut enfin passer a une action du meme noeud sans que ce soit 
necessairement la suivante en positionnant NACT plus le num6ro d'ordre de Taction 
a atteindre par la branche Choix et en retournant NACT. Le traitement se poursuit 

25 tant que Ton n'est pas passe sur une action de sortie, dont la fonction associee est 
de fermer les fichiers restes ouverts dans la base de donn6es et de liberer les 
espaces memoires. 

On observe que cela ne signifie pas forcement que Ton est revenu a la racine 
ou que Ton a parcouru tout le diagramme ou toute autre condition de cet ordre. II est 
30 aussi possible de sortir « en urgence » de Tapplication avec certaines routines de 
traitement d'erreurs qui envoient un message et ferment ou cloturent la session. 

On comprend que le systeme, lors du passage dans les menus, interprete les 
entrees clavier. Si une touche de fonction (de F1 a F9 dans la version standard) est 
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tapee, on descend immediatement sur la branche courante, a laquelle on concatene 
un caractere entre « 1 » et « 9 ». n peut ainsi tracer le chemin parcouru depuis le 
debut. II existe par ailleurs une variable globale de debuggage, qui affiche, lors des 
parcours des diagrammes, le nom de ? la branche courante en bas d'ecran et permet 
5 de controler le bon deroulement de la procedure et d'identifier rapidement les erreurs 
commises dans la numerisation des processus. 

Cependant, si une action positionne, par exemple, Choix a « 7 », hen ne 
permet de savoir, a la lecture des sources du diagramme, si la branche obtenue est 
atteinte suite a une entree clavier, ou suite a un traitement. On conseille au 
10 concepteur de reserver des valeurs de Choix menu dans I'intervalle [1-9] aux 
branchements obtenus dans un menu, et d'affecter des valeurs alphabetique pour les 
branchements declenches autbmatiquement par le contexe applicatif. 

On note que si la derniere action d'un diagramme ramene la valeur NEXT, le 
systeme trouve une erreur et s'arrete, de meme que si on cherche a descendre 
15 lorsque Ton se trouve deja sur une feuille, ou si on cherche a remonter en etant deja 
a la racine. 

Lancement des diagrammes. 

Le nom du premier diagramme lance depend de Tactivite desiree. II est lance 
a la fin du main par un appel & la fonction d'interpr6tation de diagramme. Cette 

20 routine prend bien sur le nom du diagramme en argument, mais aussi le numero de 
Taction qui est executee en premier. En effet, on veut parfois eviter de debuter a 
Taction 0, les premieres actions pouvant par exemple effectuer des initialisations 
indesirables. On donne aussi les arguments type_arbre et no_arbre qui donneront 
leurs valeurs aux variables tp_arb et no_arb. Ces variables permettent de determiner 

25 le type de diagramme, c'est-a-dire s'il s'agit d'un diagramme de Saisie, de Liste ou 
d'lmpression, pour parler des types standards, ou un autre type si besoin est. 
Comme plusieurs modules peuvent avoir le meme type (par exemple, les modules 
clients, fournisseurs et articles peuvent etre tous des Saisies), on les distingue par un 
numero d'ordre no_arb. Ce num6ro depend de la generation des cartes par le 

30 gen6rateur 3/ Ces variables permettent de relier les tables de parametres 
personnalis6s d'un module a un processus commun standard (voir saisies de fiches 
simples ou de fiches de listes, impression, d6clenchements d'alerte). 
Lancement de diagrammes particuliers 
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II est parfois interessant, depuis une action donnee, de lancer un traitement 
complet se trouvant a un endroit distant de I'arborescence, et une fois celui-ci fini, de 
se retrouver a son point de depart. Cela est rendu possible par le fait que, bien que 
tous les diagrammes de I'application soient regroupes dans un meme tableau, celui- 
5 ci regroupe en fait une foret On peut lancer une arborescence nouvelle comme un 
lien avec un « sous-processus » ou "sous-systeme" en terme cybernetique, a I'aide 
de Taction de lancement d'un diagramme, tout comme « main() » lance le 
diagramme initial. C'est meme ainsi que les divers modules sont integres a 
I'application. On utilise un diagramme existant decrivant un module, on lui donne un 
10 nom, et, depuis notre arborescence d'origine, on lance le diagramme en question. 
On sort de ce diagramme particulier par une action ramenant ENDA. 

Diagrammes clients et diagrammes communs 

Les diagrammes clients sont des diagrammes specifiques a une application. 
Les diagrammes communs sont des « objets proceduraux », permanents et 
15 accessibles par I'appel a des cartes identifiant les travaux a realiser et les 
informations necessaires pour obtenir le deroulement d'une procedure specifique 
suivant un modele standard (objet procedural) : nom des fichiers et ecrans, noms 
des menus et messages, diagrammes de traitement a executer a des moments 
precis de la procedure (par exemple : fin de la selection d'une fiche a mettre a jour). 
20 Certains ensembles de traitements vont etre utilises dans toutes les applications. Par 
exemple, les processus de saisie de liste, de Saisies, d'impressions, etc ... sont 
communs. Dans le cas des Saisies, par exemple, on a toujours un menu proposant 
un choix de type : 

CREATION 
25 MISEAJOUR 

CONSULTATION 

SUPPRESSION 

FIN 

puis, apres selection de MISE A JOUR, on a un choix, par exemple : 
30 PREMIER 
DERNIER 
SELECTION 
FIN 
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puis, apres selection de PREMIER, par exemple : 
PREMIER 
DERNIER 
SUIVANT 
5 PRECEDENT 
SELECTION 
VALIDATION CHOIX 
FIN. 

Les d6roulements de ces diagrammes sont fixes de fagon permanente dans 

10 des procedures standard. II suffit de fournir les identificateurs d'ecrans et de fichiers 
utilises, et ces diagrammes vont les visualiser, modifier les menus au fur et a mesure 
des etapes, etc ... Le mecanisme de la procedure est toujours identique, mais son 
contenu est adapte, sur mesure, aux besoins exprimes par les utilisateurs. Bien 
entendu, un certain nombre de points d'entree subsiste pour inserer des actions 

15 particulieres a chaque client, par exemple si le mode de lecture des donnees est tres 
particulier (par exemple, si le fichier n'est pas un fichier standard mais est importe 
d'un autre systeme, la fagon de lire la premiere fiche n'est pas standard, done doit 
etre donnee par le concepteur). Par contre, le fait d'avoir le choix de demander la 
premiere fiche reste standard, done le diagramme considere est utilisable. 

20 L'ensemble des informations propres a chacun des applicatifs est reuni de fagon 
structure dans des "cartes" (voir ci-apres) : le concepteur "cable" une carte pour 
approprier le processus standard a chaque processus particulier 

Les traitements particuliers a certains clients qui ne sont pas generalisables 
sont codes sous forme de diagrammes specifiques et d'actions. Ceux-ci ont 

25 exactement la meme structure que les diagrammes standards, mais sont places 
dans un tableau secondare, done ne sont pas compiles avec les applications n'y 
accedant pas. Notons que la recherche des noms diagrammes par le systeme 
commence toujours par les diagrammes clients. II est ainsi possible de definir son 
propre diagramme client et de lui donner le meme nom qu'un diagramme commun 

30 dont on n'apprecie pas le comportement. C'est le diagramme client qui sera pris a la 
place. On ne peut, en revanche, demander explicitement 3 utiliser la version client ou 
la version commune d'un diagramme. 

Lancement d'actions supplementaires 
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Parfois, le nombre d'actions maximal d'un diagramme n'est pas suffisant pour 
effectuer un traitement. II existe plusieurs methodes pour regler ce type de 
problemes. On peut aussi lancer une action particuliere qui permet de se rebrancher 
sur un diagramme avec un retour a Taction suivant Taction de branchement 
5 (hypernavigation). 

Sur chaque champ d'ecran, on peut declencher des diagrammes, a Tentree du 
champ et a la sortie (attribution de valeurs, calculs instantanes, ...) 

Cartes 

Les cartes sont des ensembles de parametres permettant d'orchestrer le 
10 comportement des diagrammes qui lui sont relatifs. Elles regroupent la plupart des 
informations utiles pour la gestion des divers modules constitutifs d'une application, 
par exemple le nom des fichiers concernes, des ecrans de Saisie, d'en-tete et de 
liste si besoin est, les noms des champs de cle pour les lectures/ecritures de 
donnees, des drapeaux (flags) de controle de traitements, les noms des menus a 
15 afficher en bas des ecrans, les actions specifiques a lancer dans le deroulement des 
diagrammes, etc ... 

Une carte est une structure regroupant un certain nombre d'entrees 
numeriques non signees, et un certain nombre de chames de caracteres. Nous ne 
considerons que le cas des donnees numeriques, la discussion etant similaire pour 
20 les cartes concernant des donnees de type « caractere ». 

On distingue, en general trois types de cartes, correspondant aux trois grands 
types de traitement, les cartes de Saisies, les cartes de Listes et les cartes 
d'impression. La difference entre chaque type reside seulement dans le nombre et la 
signification des entrees de la structure le representant. 
25 [.'identification de ces cartes est donnee par deux parametres tp_arb et 

no_arb, connus a tout instant par Tenvironnement de navigation, et permettant de 
savoir dans quel type de module de ('application Tutilisateur travaille (saisie simple, 
saisie de liste, impression, ... et sur quel sujet : article, stocks ...). 

Toutes les structures cartes d'un type donne sont regroupees dans un tableau 
30 (on a done trors tableaux principaux), et une table de regroupement, cart[], regroupe 
les structures pointeurs de chaque tableau. L'ordre des divers types de cartes dans 
ce tableau est le suivant : 
0 Reserve 
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1 Saisie des listes 

2 Saisie simple 

3 Reserve 

4 Impressions 
5 5 Reserve 

On decrit ci-apres comment referencer un parametre dans une carte. Chaque 
donnee d'une carte est identifiee dans les actions standards sous la forme : type de 
parametre (numerique ou alpha) x 1 000 + numero d'ordre du parametre dans le 
descriptif de la carte, par exemple 58. Le coeur du moteur 71 reconnait que la 
10 donnee provient de la carte en cours et fait une double indirection vers la carte du 
processus en cours, puis vers la 58 e position dans cette carte. Ce traitement est 
automatiquement fait par Texecuteur d'actions, fournissant ainsi a celles-ci les 
bonnes valeurs. Ce type d'interpretation est fait non pas par Taction elle-meme, mais 
par le mecanisme d'interpretation des diagrammes du coeur du moteur 71 . 
15 Ce principe permet, par exemple, a une meme action de visualisation 

d'afficher des ecrans differents suivant la carte dans laquelle on se trouve, tout en 
conservant les memes parametres d'appel. II suffit d'avoir modifie auparavant la 
table de parametres indexes. 

Ce type d'interpretation est fait non pas par Taction elle-meme, mais par le 
20 mecanisme d'interpretation des diagrammes ("cablage" de la carte). En d'autres 
termes, une action comporte des donnees soit decrites de fagon specifique soit 
decrites par des parametres (carte + numero dans la carte). 

Si les champs sont des champs de cles, le nceud peut proceder a des tests 
pour verifier leur validite (la fiche doit exister en mode "mise a jour" et ne doit pas 
25 exister en mode M creation M ). Les fonctions de saisie standard vont ensuite passer sur 
tous les champs sauf sur les champs de cles. Apres la creation de la cle ou la 
selection d'une fiche en mise a jour, la procedure passe dans une phase de saisie 
courante et traite les champs accessibles. 

Niveau 

30 Une lisfe de structures chamees allouees dynamiquement par le systeme 

permet d'obtenir, a tout moment, des informations interessantes concernant T6tat 
courant de Tapplication. Ces structures dites structures niveau, regroupent 
notamment : 
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- le norn du diagramme courant (nom) 

• I'index de Taction dans le diagramme courant (nact) 

- le nom de la carte (tp_arb) 

- I'index de la carte dans la table des cartes (no__arb) 

5 Le systeme alloue une telle structure a chaque descente ou a chaque lancement 
d'un diagramme. Les structures sont liberies en fin de diagramme ou apres 
remontee. 

Transferts, insertions et extractions 

L'essentiel des traitements effectues consiste en transferts d'information d'une 
10 zone vers une autre, par exemple d'un champ de fichier, apres la lecture d'un 
enregistrement, vers un champ d'ecran permettant la visualisation de I'information 
consideree. Les structures d'ecrans/fichiers permettent jusqu'a trois codages de 
transferts. Un codage tient sur un unsigned int (32 bits) et a I'aspect suivant : 

type de la donnee (fichier, ecran), nom du fichier ou de Tecran, nom du 
15 champ. 
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REVINDICATIONS 

1 - Precede de generation de logiciel applicatif de gestion d'un processus, 
caracterise en ce qu'il met en oeuvre un logiciel systeme commun a tous les logiciels 

5 applicatifs et en ce qu'il comporte : 

- une etape de representation du processus (32), mettant en oeuvre un tres petit 
nombre de classes d'actions ou objets generiques, typiquement inferieur a vingt, 
dans au moins un diagramme de I'application, 

- une etape de transcription (33) de chaque objet de chaque diagramme en une 
10 action correspondant a un objet dote d'attributs, chaque classe d'action ou objet 

generique etant, pendant I'etape de transcription, associe a une interface de 
saisie de donnees d'application, 

- une etape de transcription des noeuds, embranchements et feuilles (34) de 
chaque diagramme en une action correspondant a un objet dote d'attributs, 

15 - une etape de pre-compilation (35) au cours de laquelle on verifie que les 
attributs des objets necessaires pour la logique de fonctionnement de I'application 
existent et sont convenablement fournis, en syntaxe, 

- une etape de compilation (36) au cours de laquelle les descriptifs de donnees 
des objets dotes d'attributs sont integres et sont assembles avec le logiciel 

20 systeme, pour obtenir un logiciel applicatif executable, et 

- une etape d'execution (37) du logiciel applicatif executable. 

2 - Procede selon la revendication 1, caracterise en ce que, au cours de I'etape de 
transcription d'objets (33), au moins une action lance un traitement complet se 
trouvant a un endroit distant d'une arborescence correspondant audit au moins un 

25 diagramme, et une fois celui-ci termine, retourne a son point de depart. 

3 - Procede selon Tune quelconque des revendications 1 ou 2, caracterise en ce que, 
au cours de I'etape d'execution (37), le logiciel applicatif executable met en oeuvre 
une bibliotheque de gestion du deroulement des processus correspondant audit au 
moins un diagramme, ladite bibliotheque constituant un automate (70) qui gere le 

30 deroulement des processus et execute les operations qui les jalonnent, le 
deroulement des operations etant defini, dans le referentiel applicatif, a I'aide de la 
methode (10), en decrivant les flux reels. 



WO 03/085521 PCT/FR03/01019 

34 

4 - Precede selcn I'une quelconque des revendications 1 a 3, caracterise en ce que, 
au cours de I'etape de compilation (36) ou au cours de I'etape d'execution (37), il met 
en oeuvre un moteur (71) qui comporte un superviseur charge de reconnaitre la 
configuration materielle et de communication. 
5 5 - Procede selon la revendication 4, caracterise en ce que le moteur (71) gere une 
ou plusieurs bases de donnees d'apres un descriptif des fichiers de donnees fourni 
par le referentiel applicatif, e'est-a-dire une liste des informations contenues dans 
chaque fiche et la liste des index d'acc^s, avec une liste des champs servant a 
constituer chacun de ces index, les liens entre des codifications multiples d'un meme 
10 item dans plusieurs services, plusieurs sites ou plusieurs entreprises. 

6 - Proc6de selon la revendication 5, caracterise en ce que les bases de donnees 
sont synchronisees selon une frequence determinee par le diagramme, a la 
demande ou avant certains evenements predetermines. 

7 - Procede selon Tune quelconque des revendications 1 & 6, caracterise en ce que 
15 I'etape de transcription d'objets (33) comporte, pour programmer chaque action : 

- une etape de nommage (331) au cours de laquelle on donne un nom a ladite 
action, 

- une etape de definition de fonction (332), au cours de laquelle on met ladite action 
en correspondance avec une tache, et, 

20 - une etape de definition d'information (333), au cours de laquelle on designe les 
informations qui seront traitees dans Taction. 

8 - Procede selon la revendication 7, caracterise en ce que I'etape de compilation 
(36) remplace le nom d'action donne, au cours de I'etape de nommage (331), par le 
transcripteur, par un index dans une table de taches. 

25 9 - Procede selon I'une quelconque des revendications 1 a 8, caracterise en ce que, 
au cours des etapes de representation (31) et de transcription (32, 33), ledit au 
moins un diagramme correspond a au moins une arborescence dans laquelle les 
nceuds et feuilles, ou le code est effectufe, sont composes d'actions, les valeurs de 
retour de ces actions determinant le deplacement dans I'arborescence. 
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